Professional Cloud Security Practice Exam — Professional Cloud Security

The scenario requires a Compute Engine instance to be fully restricted from both public internet access and access to any Google APIs or services. To meet this requirement, two core network configuration settings must remain disabled. First, disabling public IP assignment eliminates the instance’s ability to route traffic to the public internet via the default VPC internet gateway, blocking public internet and public Google API access. Second, disabling Private Google Access removes the private network path for the instance to reach Google APIs and services without a public IP, ensuring no Google service connectivity is possible. This combination of controls aligns with GCP network security best practices tested in the Professional Cloud Security Engineer certification, specifically the domain of designing secure network architectures for isolated workloads. Option Analysis: A. Public IP: Correct. A public IP assigned to a Compute Engine instance enables default outbound connectivity to the public internet and public-facing Google APIs via the VPC’s internet gateway. Disabling public IP assignment removes this access path, which is a mandatory control to meet the scenario’s requirement of no internet access. B. IP Forwarding: Incorrect. IP forwarding allows an instance to process traffic with source or destination IPs that do not match its own network interface IP, typically used for network appliances like load balancers or firewalls. It does not control access to the internet or Google APIs, so disabling it is not required for this use case. C. Private Google Access: Correct. Private Google Access is a subnet-level setting that allows instances without public IPs to access Google APIs and services over GCP’s private network, without traversing the public internet. Disabling this setting blocks all private path access to Google APIs and services, fulfilling the requirement of no access to Google services. D. Static routes: Incorrect. Static routes are custom user-defined routes that direct traffic between subnets, on-premises environments, or external networks. While misconfigured static routes could enable unintended access, the requirement specifies settings that must remain disabled, not route modifications. Disabling static routes is not required, as even without custom static routes, the instance could still access resources if public IP or Private Google Access are enabled. E. IAM Network User Role: Incorrect. The IAM Network User role grants permissions to provision resources using existing VPC networks, it does not control a running instance’s runtime network access to the internet or Google APIs. Disabling this role has no impact on the instance’s connectivity, so it is irrelevant to the scenario. Key Concepts: 1. Compute Engine Public IP Management: This foundational network control determines if an instance has a routable public IP address, directly enabling or disabling default public internet access. It is a core component of least-privilege network design for workloads that do not require public connectivity. 2. Private Google Access Configuration: This subnet-level setting controls private connectivity between VPC instances and Google APIs/services without public IPs. Disabling this control is required for fully air-gapped workloads that cannot access any Google services, a common requirement for highly sensitive workloads. 3. VPC Outbound Access Controls: The combination of public IP assignment rules and Private Google Access configuration forms the base layer of VPC outbound traffic restriction, a key topic in the Professional Cloud Security Engineer network security domain. References: Configure Private Google Access, Google Cloud Documentation, https://cloud.google.com/vpc/docs/configure-private-google-access Compute Engine IP Addresses, Google Cloud Documentation, https://cloud.google.com/compute/docs/ip-addresses

The Professional Cloud Security Engineer certification assesses expertise in designing and implementing VPC network security controls, including understanding default baseline security configurations that apply to all Google Cloud VPC environments. Implied firewall rules are non-deletable, lowest-priority (priority value 65535) rules automatically enforced on every VPC network, with no user configuration required. These rules set the default traffic behavior when no higher-priority user-defined firewall rule matches a traffic flow. The question asks for the two standard implied rules, which are the default allow all outbound and deny all inbound rules, so options A and B are the correct responses. Recognizing these default controls is critical for evaluating baseline VPC security posture and designing custom rule sets that meet organizational access requirements while overriding default behavior only when necessary. Option Analysis: A. Correct. Google Cloud VPC networks include an immutable implied allow egress rule with priority 65535 that permits all outbound connections to any destination by default. Users can only override this behavior by creating higher-priority (lower priority number) deny egress rules for specific traffic flows, so this is a valid implied firewall rule. B. Correct. The second immutable implied VPC firewall rule is a deny ingress rule with priority 65535 that blocks all inbound connections from any source by default. Users must explicitly create higher-priority allow ingress rules to permit authorized inbound traffic to workloads, so this is a valid implied firewall rule. C. Incorrect. The restriction on outbound port 25 (SMTP) traffic is a platform-level anti-spam control enforced at the Google Cloud edge, not a VPC implied firewall rule. This restriction applies to most project types and cannot be overridden via standard VPC firewall configuration, so it does not meet the definition of an implied VPC firewall rule. D. Incorrect. There is no implied deny all outbound connections rule for VPC networks. The default implied egress rule explicitly allows all outbound traffic, so this option is the opposite of the actual default implied egress behavior. E. Incorrect. There is no default implied rule allowing inbound port 80 (HTTP) traffic. All inbound traffic is blocked by default via the implied deny ingress rule, so users must manually create explicit allow ingress rules for port 80 if they want to expose HTTP services to external or internal clients, making this option incorrect. Key Concepts: 1. Implied VPC Firewall Rules: These are non-deletable, lowest-priority (65535) rules automatically applied to all VPC networks, consisting of an allow all egress rule and a deny all ingress rule, that form the default baseline for VPC traffic filtering. 2. Firewall Rule Priority Evaluation: Firewall rules are evaluated in ascending order of priority value, meaning lower numeric priority values correspond to higher precedence. User-defined rules with priority values lower than 65535 can override the behavior of the implied rules for targeted traffic flows. 3. Platform Restrictions vs VPC Firewall Controls: A key distinction exists between VPC-level firewall rules (which users can customize with additional allow/deny rules) and platform-wide edge restrictions (such as the default SMTP port 25 block) that are enforced independently of VPC firewall configuration and cannot be modified via standard firewall rule changes. References: VPC Firewall Rules Overview, https://cloud.google.com/vpc/docs/firewalls#implied_rules Professional Cloud Security Engineer Exam Guide, https://cloud.google.com/certification/guides/cloud-security-engineer

The core requirement in this scenario is to eliminate plaintext secrets from source code management systems, which is a critical cloud security best practice to prevent unauthorized access to sensitive credentials, API keys, and other confidential data. The suggested answer B aligns with Professional Cloud Security Engineer data protection and encryption domain requirements. Encrypting secrets with a Customer-Managed Encryption Key (CMEK) ensures the customer retains full control over encryption key lifecycle, access permissions, and audit logging for encryption operations, rather than relying solely on Google-managed encryption keys. Storing the encrypted secrets in Cloud Storage means plaintext versions of secrets are never committed to SCM: development code only references the encrypted Cloud Storage object, and secrets are decrypted at runtime by authorized identities with explicit IAM permissions to access both the Cloud Storage object and the CMEK. This approach fully addresses the risk of plaintext secret exposure in SCM while adhering to GCP security best practices for sensitive data storage. Option Analysis: A. Option A is incorrect. Storing secrets in Cloud SQL without explicit encryption controls does not address the risk of plaintext secret exposure, as the option does not include any mechanism to encrypt secrets at rest or in transit. Cloud SQL is a relational database service designed for structured application data, not optimized for secure secret storage, and this approach does not prevent plaintext secrets from being accidentally committed to SCM during development workflows. B. Option B is correct. Encrypting secrets with CMEK provides customer control over encryption key access and lifecycle, eliminating the risk of unauthorized parties accessing plaintext secrets even if the underlying storage is compromised. Cloud Storage supports native server-side encryption with CMEK, and storing encrypted secrets in Cloud Storage ensures no plaintext secrets are present in SCM, as secrets are only decrypted at runtime by authorized identities with appropriate IAM permissions. This approach fully meets the stated requirement and aligns with GCP security best practices. C. Option C is incorrect. The Cloud Data Loss Prevention (DLP) API is designed to detect and classify sensitive data, not to secure or encrypt secrets for long-term storage. Scanning for secrets only identifies exposure after the fact, it does not prevent plaintext secrets from being stored in SCM. Additionally, storing secrets in Cloud SQL without encryption controls does not resolve the core risk of plaintext sensitive data exposure. D. Option D is incorrect. Hosting SCM on a Compute Engine VM with local SSDs and preemptible VMs does not address the core requirement of eliminating plaintext secrets from SCM at all. Preemptible VMs are short-lived and not suitable for persistent SCM hosting, as they can be terminated by GCP at any time, leading to data loss on ephemeral local SSDs. This approach has no impact on whether secrets are stored in plaintext in the SCM system. Key Concepts: 1. Customer-Managed Encryption Keys (CMEK): CMEK is a GCP feature that allows customers to own and manage the encryption keys used to protect data at rest in GCP services, enabling granular access control, audit logging, and key lifecycle management separate from Google-managed encryption keys. This is a core data protection concept for the Professional Cloud Security Engineer certification. 2. Secret Management Best Practices: A foundational cloud security requirement is to never store plaintext secrets including passwords, API keys, and private certificates in source code repositories, as this exposes sensitive data to all users with repository access. Secrets must be encrypted at rest and accessed only at runtime via authorized, audited access controls. 3. Cloud Storage Encryption: Cloud Storage supports multiple layers of encryption for data at rest, including server-side encryption with CMEK, which ensures all objects stored in Cloud Storage are encrypted with keys controlled by the customer, reducing the risk of unauthorized access to sensitive data. References: Secrets Management Best Practices, https://cloud.google.com/security/best-practices/secrets-management Customer-managed encryption keys (CMEK) for Cloud Storage, https://cloud.google.com/storage/docs/encryption/customer-managed-keys

The scenario requires centralized management of GCP IAM permissions via on-premises Active Directory group membership, which has two core requirements: 1) ongoing synchronization of AD group objects and their memberships to Google Cloud's identity directory, and 2) the ability to assign IAM permissions to the synced groups so that access is controlled entirely by AD group changes made on-premises. The correct approach leverages Google's native managed directory synchronization tool to avoid custom development, ensure consistency between on-prem and cloud directory objects, and align with Google Cloud IAM best practices for centralized identity management, a core domain topic for the Professional Cloud Security Engineer certification. Option Analysis: A. Correct. Cloud Directory Sync (CDS) is a Google-provided, fully supported tool designed specifically to synchronize users, groups, and group memberships from on-premises Active Directory or other LDAP directories to Cloud Identity, Google Cloud's native identity directory. Once groups are synced from AD, you can directly assign IAM roles to these synced groups, and any changes to group membership made in on-prem AD automatically sync to Google Cloud, removing the need to manage groups in two separate locations. This fully meets both requirements in the scenario. B. Incorrect. SAML 2.0 SSO only handles user authentication to Google Cloud resources, it does not synchronize group objects or ongoing membership changes from on-prem AD to Google Cloud. While SAML assertions can include group attributes for just-in-time user provisioning during authentication, this does not support centralized, ongoing group management for IAM permission assignment, as groups are not persisted and synced in the Cloud Identity directory. C. Incorrect. The Cloud IAM API is used to manage IAM policy bindings for GCP resources, it does not support creation or management of Cloud Identity groups. Building a custom integration to pull groups from AD and create them via separate APIs would require ongoing custom development and maintenance, introduces risk of directory inconsistency, and is not the recommended native solution for this use case. D. Incorrect. While the Admin SDK can be used to programmatically manage Cloud Identity groups, building a custom sync integration between AD and the Admin SDK is unnecessary when Cloud Directory Sync is the native, managed, fully supported solution for AD to Cloud Identity synchronization. Custom sync implementations introduce operational overhead, higher risk of configuration error, and do not align with Google Cloud recommended best practices for directory synchronization. Key Concepts: 1. Cloud Directory Sync (CDS): CDS is the official Google tool for synchronizing on-premises LDAP directory objects including Active Directory users, groups, and memberships to Cloud Identity, ensuring consistent identity data between on-prem and Google Cloud environments with no manual dual management. 2. IAM Group-Based Access Control: Assigning IAM permissions to groups rather than individual users reduces administrative overhead and simplifies access governance. Using groups synced from a central identity source like on-prem AD enables consistent access policy enforcement across on-prem and cloud infrastructure. 3. Authentication vs Directory Synchronization: SAML 2.0 SSO addresses authentication which is verifying user identity, while directory synchronization addresses authorization-related identity object management including syncing groups and memberships to assign IAM permissions, two separate components of a cloud identity and access management strategy. References: Synchronize users from Active Directory or LDAP to Cloud Identity, Cloud Directory Sync overview

This question assesses core container image hardening knowledge, a key domain for the Professional Cloud Security Engineer certification focused on reducing cloud workload attack surfaces and enforcing least functionality principles. The suggested answers B and C are aligned with industry-standard and cloud provider-endorsed secure container build practices. Packaging a single application per container reduces operational and security complexity, limits potential exploit paths, and simplifies vulnerability management by limiting the scope of dependencies to only what is required for that single application. Removing unnecessary tools directly reduces the container attack surface by eliminating unused binaries, shells, package managers, and utilities that an attacker could leverage to escalate privileges, execute malicious code, or exfiltrate data if the container is compromised. Both controls directly reduce risk for containerized workloads in cloud environments. Option Analysis: A. Incorrect. While running an application as PID 1 can create unanticipated signal handling behavior, it is not a formal security requirement to avoid running apps as PID 1 for secure image builds. Many properly configured production containers run apps as PID 1 safely, and this is not a tested secure build best practice for the certification. B. Correct. Packaging a single application per container is a foundational secure container design and build principle. This practice eliminates the risk of unneeded additional services or software introducing vulnerabilities, simplifies vulnerability scanning and patch management, and limits the blast radius if a container is compromised by ensuring no unrelated applications are affected by a breach. C. Correct. Removing all unnecessary tools, libraries, and utilities not required for the target application to run is a core least functionality control for container hardening. Unnecessary components such as debug tools, shells, or system package managers provide additional vectors for attackers to exploit during a compromise, so removing them reduces the overall attack surface of the container image. D. Incorrect. Using arbitrary public container images as a base is a high-risk practice, as unvetted public images often contain unpatched vulnerabilities, hidden malware, or insecure default configurations. Secure build practices recommend using only hardened, regularly scanned, verified base images, either from trusted official public repositories or private internally maintained repositories, not general public images as stated in the option. E. Incorrect. Container image layers are additive and all layers remain accessible even if data is deleted in a subsequent layer. Attempting to hide sensitive information with extra layers is ineffective, as attackers can easily extract sensitive data from lower layers of the image. Secure build practices mandate avoiding inclusion of sensitive data in any image layer entirely, rather than attempting to hide it with additional layers. Key Concepts: 1. Container Attack Surface Reduction: This core cloud security principle focuses on minimizing the set of software, utilities, and access points present in a container to only the components strictly required for the hosted application to function, reducing the number of potential vulnerabilities an attacker can exploit. 2. Single Service Per Container: A foundational container security and operational best practice that requires each container to host only one application or service, simplifying security monitoring, patching, and incident response while limiting the blast radius of a potential container compromise. 3. Container Image Hardening: The standardized process of modifying base images and build pipelines to eliminate known vulnerabilities, remove unnecessary components, and enforce secure default configurations before container images are deployed to production environments. References: Google Cloud Best practices for building secure container images, https://cloud.google.com/architecture/best-practices-for-building-containers NIST SP 800-190 Application Container Security Guide, https://csrc.nist.gov/publications/detail/sp/800-190/final